BBS in a Box 12/BBS in a box XII-2.iso/Files II/Prog/M/MacWT 0.04.sit/WT Docs/README-0.03

Text File | 1994-05-18 | 8.6 KB | 217 lines

wt - a 3D game engine

Copyright (C) 1994 by Chris Laurel

Please see the LICENSE file for further details.  You may not distribute
this project without this file (README) and the LICENSE file included.

---------------------------------------------------------------------------

This is still a preliminary version of my 3D game engine, wt.

* In the proud tradition of cp, mv, rm, as, and cc, now there is 'wt'
  wt (never capitalized) stands for "what's that?"

* This is not by any means a complete game.  It is just a demo of my
  graphics engine.  I'd never name a game wt.

* wt is portable software.  See the section on porting at the end of this
  README for information on what to change in order to port to another
  platform.

* Features:

    * Easy to edit world file.  Just haul out your favorite text editor
      and modify 'castle.world'  Or create your own .world file from
      scratch.  Whee.  Just don't get carried away because the world
      file format will be changing before the next release.

    * No BSP trees were killed to make this program.  Sorry . . . it's
      late.  BSP trees are elegant and fast *if* your environment is
      static.  I eventually want walls in wt that move and change shape.
      However, if I can't kill a bug having to do with walls perpendicular
      to the view plane, I may have to resort to a BSP tree for determining
      wall visibility (or if my current algorithm is too slow for worlds
      with a large number of walls.)

    * Variable texture map size.  Texture maps for walls can be any
      width you like, but the height must be either 64 or 128.  Floor
      textures must be either 64x64 or 128x128.  The main reason why
      arbitrary powers of two aren't supported has to do with the fact that
          Intels x86 chips don't have enough registers for my innermost loops.

    * Texture scaling for walls.  The walls have an x scale factor and
      a y scale factor.  It might be more properly called 'frequency,'
      since the smaller the parameter, the bigger the texture map will
      appear.  Supporting the scaling factors requires a couple of extra
      multiplies in the wall drawing function.


* Running the wt and xwt demos

    * For xwt, just type 'xwt castle.world'  The keys are:
        forward - up arrow
        backward - down arrow
        turn left - left arrow
        turn right - right arrow
        strafe - slash
        run - shift
        jump - space
        quit - q

            Alt or Meta should also be useable as strafe keys, but my
            version of X distributions as the Alt key mapped to something
        else.

    * To run wt, you need to be root (or make it setuid root first.)
        As root, type 'wt castle.world'  The keys are the same as for the
        X version, except that the slash does not work for strafing.


* Resources

    * A wt mailing list has been started recently.  Topics will include
        improving the engine design and adding features, porting the
        engine to different architectures, and game design using the wt
        graphics engine.  The addresses are:

        to subscribe:  [e-mail]
            to post a message: [e-mail]

    * The wt ftp site is magoo.uwsuper.edu.  wt related files will be
        located in the /pub/games directort.


* Responses

    * While wt does look similar in many respects to DOOM, it is not
      based on any DOOM source code, and I have no connection with Id
      software other than being a customer.

    * I will add mouse support for the X11 and svgalib versions.  I also
      want to support the Linux keyboard better by setting it to
      RAW mode.

    * Your X server needs to support the MIT shared memory extension
      in order for wt to run.  Also, it only currently supports an
      8-bit pseudo color visual.  I just haven't had a chance to perfect
      the X code.

    * I will eventually design a world editor.  It will run under X and
      be based on Tcl/Tk.

    * Pitch and roll will not be supported.  It's a fundamental constraint
      of the engine design.

    * Weird things will happen when you jump above the tops of buildings
      or though the ceiling.  You cannot see the tops of buildings--this
      is another design limitation.

    * Resizing the view window . . . this does need to be supported.  The
      reason why it is not currently supported again has to do with the
      limited register set of the x86 chips.  I wanted to keep all my
          variables in registers in the innermost loop, but they would not
      all fit.  So, I made the view width an immediate constant . . . if
      I can coax gcc to let me use the ebp register, I'll use that to
      hold the width.  Or I could just deal with the (probably minor)
      speed degradation I'd get by reading it from memory.


* Room for improvement

    * Optimizations.  There are some obvious ones that I have not gotten
      around to implementing yet.  I think that the floors code
      can be sped up significantly.  If you know of any improvements to the
      assembly loops in slice.c, *tell me*.  I'm not an Intel assembly
      language guru or anything.

    * Code cleanup.  The core of wt is still in development, so some of
      the code surrounding the renderer is hacky test-the-engine stuff.
      Once wt starts developing into a real game, much of the code
      will be reorganized.  wt.c will change completely.


* 'Port away!'

    * wt now supports both big and little endian machines.  There should
      not be anything remaining in wt which is endianness dependent.

    * There are three types of #define's used to block off non-portable
      sections of the code.  ARCH_i86 surrounds the couple assembly
      routines in the wt source.  I also surround these with an
      #ifdef __GNUC__ because the inline assembly code syntax in
      gcc is different than for other x86 compilers I've seen.  (Anyone
          considering doing an DOS or Windows port take note:  the GNU
      assembler uses AT&T syntax, which has the reverse operand order
      of Intel syntax.)  Finally, there is a #define to identify
      the graphics system.

    * Substitute C routines exist for assembly language functions.
      On a RISC system with a good compiler, I figure you shouldn't need
      to recode them in assembly language.  The C functions *should* work.
      I have not tested them in a while, but they were used extensively
      before I rewrote them in assembly.

    * Before attempting to compile on a non-UNIX system, #define PROFILE
      to be zero in render.c.

    * If you've got a non-Intel system with X11 (or an Intel system
          with X11 which does not have gcc), then you should be able to
      compile wt successfully by just not defining ARCH_i86 in the
      Makefile.

    * If you're not running X11, then you'll need to write your own
      graphics and input routines and add a #define for your graphics
      system.  Check out linuxvga.c and x11graphics.c for sample
      graphics implementations.  All you need is an initialization
      function, a cleanup function, and something to blast a framebuffer
      the screen--memcpy, CopyBits or whatever . . .

    * The input system hooks are declared in input.h.  To create your
      own input module, create a file with these functions in it.
          For sample input routines, look in linux-console.c and x11input.c.
      Mac and Windows people:
      x11input.c should give you a good idea about how to tie an
      event handler into wt.

    * Send me your ports and I'll include them in the next wt distribution!
      This goes for other improvements to wt, too.

    * I'm especially interested in reports about how fast wt will run
      on different platforms (wtStones?)  If you do a port, talk to me
      about speed, especially if you have a PowerMac or Alpha system.
      If you port it to a 286, I'm interested but I might laugh.


* Future directions:

    * I'd like to see wt become a multi-platform client for an
      Internet wide MUD type game.  Or a perhaps a net-wide arcade
      game like Xpilot.  I've got a lot of other more innovative ideas
      but I'd better get the engine done before I start spouting about
      them.

* Credits

    Dan Egnor ([e-mail]) - submitted the first set of
         endian fixes.
    Dave Thomas ([e-mail]) - wrote up an Imakefile
    Pietik{inen ([e-mail]) - RAW mode keyboard patches for
         the svgalib version.
        Harm Hanemaayer ([e-mail]) - Patches to linuxvga.c to
         make better use of svgalib.
    Russ Nelson ([e-mail]) - Created the as yet unincorporated
         Tcl worldfile changes and provided lots of good advice.
    Patrick L. McGillan ([e-mail]) - Set up the wt
         mailing list and ftp site.

* Me:

    send any comments, ideas, bug reports, etc. to:

    Chris Laurel
    home: [e-mail]
    work: [e-mail]
    snailmail: 5700 W Lake St, #208
                   St. Louis Park, MN  55416